How To Check Whether The Ip Is A Japanese Native Ip And Identify Proxy, Nat And Shared Ip Phenomena

question 1: how to determine whether an ip is a japanese native ip ?

to determine whether the ip is a japanese native ip , first use an online or local geoip database (such as maxmind, ipinfo, ipapi) to query the geographical location; then perform a whois and asn query to confirm whether the operator to which the ip belongs is a local japanese isp (such as ntt, kddi, softbank, rakuten, etc.). if the geoip is labeled japan and the whois belongs to the japanese asn, there is a high probability that it is a japanese native ip.

in addition, you can check whether the reverse dns (ptr record) of the ip has the characteristics of a japanese operator or a japanese domain name. combining the ping/delay and traceroute return paths to see whether the return path is within the japanese backbone network can further improve the accuracy of the judgment.

checkpoints

main checks: 1) geoip results; 2) whois/asn attribution; 3) ptr/reverse dns pointing; 4) latency and route. if three or more items are consistent, it can be regarded as a japanese native ip.

common tools

recommended tools: ipinfo.io, whois, dig/host (view ptr), geoiplookup, traceroute/mtr, online asn query.

things to note

the geoip database has errors, especially in mobile or cdn/ip migration scenarios, and a single basis cannot be completely relied on.

question 2: how to distinguish data center ip and residential ip through whois/asn and reverse dns?

query whois to see the registrant and organization fields. data centers usually belong to cloud or hosting companies (such as amazon, google, microsoft, sakura, gmo, etc.), while residential ips belong to isps or mobile operators. it can also be determined by the asn (autonomous system number): common residential asns are ntt (as9366, etc.), kddi, softbank, etc.; while cloud service asns usually have obvious manufacturer names.

reverse dns (ptr) can usually reveal the purpose: those ending with "*.amazonaws.com", "*.linode.com" or "*.gcore.lan" are mostly data centers; those with "bbtec.net", "ocn.ne.jp" or the words home broadband are mostly residential users.

key points for identification

data center ips tend to have more open ports, more stable responses, low latency, and direct routing paths; residential ips have greater latency and jitter, and port scans show a high probability of being protected by nat or home routers.

quick hit method

you can use port scan (such as nmap) to observe common service ports, or view the service labels in passive intelligence (shodan) to assist in judgment.

exception prompt

some hosting services can rent japanese ip and customize ptr, which requires comprehensive judgment on multiple indicators. a single whois may be misleading.

question 3: how to detect whether the ip goes through a proxy (http/socks/transparent proxy, etc.)?

the server can discover the proxy by checking the request header: common header fields such as x - forwarded-for ,

in addition, curl can be used to initiate a request and observe the difference in the response (for example, the proxy will insert a specific server/via header), or by detecting whether the tcp handshake ttl, mss and other network fingerprints of the ip are consistent with the direct connection to discover transparent proxies or intermediate caches.

browser side detection

you can use webrtc/stun on the browser side to try to detect the difference between the local ip and the exposed ip: if the lan ip reported by the browser is inconsistent with the public ip seen by the server and there is an intermediate ip chain, there may be a proxy.

common proxy indicators

1) the http header carries the proxy field; 2) asn belongs to the vpn/proxy service provider; 3) the port (such as 1080, 3128) is open and the proxy id is returned.

things to note

some high-profile proxies will clear or forge headers, which need to be determined based on routing and asn information; detection at the https level is more difficult and relies on tls fingerprints or traffic characteristics.

question 4: how to identify nat (including cgnat) and shared ip ?

judging nat/cgnat can start from the ip ownership and port behavior: if a large number of customers display the same public ip, whois shows that the ip belongs to the mobile operator or is marked with a cgnat segment (for example, 100.64.0.0/10 is a cgnat reserved segment), or the isp uses large-scale nat, these are signs of nat.

if the server sees the same user-agent in different sessions but comes from the same public ip and the port allocation is regular (the port changes within a short period of time), it means there may be nat/shared ip behind it. another method is to require the client to send back the lan private ip (reported through js or application). if multiple users report the same private network segment and the same public network, it is likely to be nat.

key points of cgnat recognition

common characteristics of cgnat: extremely large number of connections from the same ip, restricted ports, remapped upload source ports, and whois/asn displayed as mobile or home isp.

troubleshooting steps

1) count the number of concurrent connections of the same ip; 2) check the private ip reported in the session; 3) query the asn and reserved segment list; 4) collaborate with users to test port mapping.

additional information

shared ip may be caused by a proxy, vpn or cdn, while nat is when multiple users at the network level share the same public address. the two must be comprehensively judged through header information, session behavior and network routing.

question 5: practical tools and steps: how to use them , ping, webrtc, and online services to comprehensively determine the ip source and whether it is a proxy/nat/shared ip?

it is recommended to follow the steps: 1) use geoip and whois to quickly determine geography and asn; 2) use observe the routing hop count and whether the routing node is in the japanese backbone (such as ntt switching point); 3) use check the ptr record to see if it belongs to an isp or cloud vendor; 4) check the difference between the local private ip and the public ip through webrtc/stun in the browser; 5) use curl to check whether there is a proxy field in the http header; 6) if available, use nmap or shodan to check whether the ip is a data center or an open proxy.

based on this information: geoip+whois+ptr is consistent and the traceroute path is in japan, and there is no proxy header, and the asn is a japanese isp, it is a japanese native ip; if the header or asn points to a vpn/proxy service provider or there are signs of a large number of concurrent connections and port mapping, it may be a proxy or nat/shared ip.

tool list

recommended tools and services: whois, dig/host, traceroute/mtr, ping, curl, nmap, ipinfo/ipapi/maxmind, shodan, webrtc/stun debugging page.

practical suggestions

combine multiple evidence judgments to avoid misjudgment with a single tool. for high-risk or important determinations, an automated detection process can be configured to summarize the whois/asn, geoip, http header and traceroute results into a scoring model.

legal & privacy tips

when testing, pay attention to comply with isp and regional laws and regulations, avoid unauthorized active scanning or intrusive testing, and respect user privacy.